Building and maintaining a network

ABSTRACT

Techniques and systems for establishing and maintaining networks. The technique includes assigning a network device to an interregional redirector system and load balancer systems. The network device can be assigned based upon the regions or subregions of the network device. The technique includes the load balancer systems assigning the network device to network device management engines. The status of the network device management engines can be monitored to determine if one of the network device management engines has failed. In the event that a network device management engine has failed, the network device can be assigned to a different network device management engine.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/158,661 filed Jan. 17, 2014, now U.S. Pat. No. 10,389,650, whichclaims priority to U.S. Provisional Patent Application Ser. No.61/788,621 filed Mar. 15, 2013, which are hereby incorporated herein byreference.

BACKGROUND

An area of ongoing research and development is improving the ease bywhich a person or an enterprise can set up a network. Of particularimportance is improving the ease by which a person or an enterprise canadd devices to an already existing network to further expand and improvethe network. Specifically, in establishing a network or adding devicesto an already existing network, an administrator must configure thedevice in order to establish a new network or incorporate a new deviceinto an already existing network. There therefore exists a need forsystems in which a person or an enterprise can easily setup a network oradd devices to an already existing network without having to configurethe device.

Another area of ongoing research and development is improving the easeby which a network can be monitored and managed to continue to functionif a device fails. Typical systems usually connect a plurality ofnetwork devices to a single server to manage the network device.Therefore, if the server fails, all of the network devices managed bythe failed server are inoperable. There therefore exists a need for asystem that monitors the servers or engines that manage network devicesto determine whether or not they have failed. There also exists a needfor a system capable of reassigning the network devices to differentservers or engines that manage network devices in the event that aserver or engine that manages network devices has failed.

The foregoing examples of the related art are intended to beillustrative and not exclusive. Other limitations of the relevant artwill become apparent to those of skill in the art upon a reading of thespecification and a study of the drawings.

SUMMARY

The following implementations and aspects thereof are described andillustrated in conjunction with systems, tools, and methods that aremeant to be exemplary and illustrative, not necessarily limiting inscope. In various implementations, one or more of the above-describedproblems have been addressed, while other implementations are directedto other improvements.

Techniques and systems for building and maintaining a network. Thetechnique involves assigning network devices to device managementengines that mange the flow of data packets into and out of the networkdevices. The technique can include connecting a network device to aninterregional redirector system. The network device can be a newlypurchased device that is being powered on for the first time by thepurchaser. The technique can include the interregional redirector systemreceiving network device information about the network device. Thetechnique can also include the interregional redirector systemvalidating the network device. The interregional redirector system canthen assign the network to a load balancer system. The load balancersystem can be associated with or part of one or multiple regional devicemanagement systems. The regional device management systems can beregionally unique in that they contain engines in specific regions orsubregions. The load balancer systems can be regionally unique in thatthey are associated with or part of one or multiple regional networkdevice management systems that are regionally unique. The interregionalredirector system can assign the network device to a load balancer basedupon the regions or subregions of the engines of the regional networkdevice management systems or the engines themselves that which the loadbalancer systems are associated.

The technique can also involve a load balancer system assigning anetwork device to a network device management engine. The load balancersystem can receive both network device information and network devicemanagement engine information. The load balancer system can assign thenetwork device to a network device management engine based upon theregions or subregions of the network devices and the regions orsubregions of the other network devices that they network devicemanagement engine already manages.

The technique can also include the load balancer system monitoring thestatus of the network device management engines associated with it andreassign network devices to different management engines in the eventthat one of the management engines fails. The load balancer system canmonitor the status of the network device management engines associatedwith the load balancer system by retrieving network device managementengine status messages from a network device management engine messagequeue. The status messages can be sent to the network device managementengine message queue by the network device management engines. The loadbalancer system can use the status messages of the network devicemanagement engines to determine whether or not a network devicemanagement engine has failed. If the load balancer system determinesthat a network device management engine has failed, then the loadbalancer system can reassign the network device to another networkdevice management engine that is not failing. The load balancer systemcan also send a notification to an administrator system that the networkdevice management engine has failed.

These and other advantages will become apparent to those skilled in therelevant art upon a reading of the following descriptions and a study ofthe several examples of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a diagram of an example of a system configured to couplea network device to a regional network device management system.

FIG. 2 depicts a diagram of an example of a system configured to couplea network device to a network device management engine and monitor thenetwork device management engine.

FIG. 3 depicts a diagram of an example of a load balancer system.

FIG. 4 depicts a flowchart of an example of a method for assigning anetwork device to a regional network device management system.

FIG. 5 depicts a flowchart of an example of a method of a load balancersystem for assigning a network device to a network device managementengine.

FIG. 6 depicts a flowchart of an example of a method for determiningthat a network device management engine has failed by a network devicemanaged by the network device management engine.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1 depicts a diagram 100 of an example of a system configured tocouple a network device to a regional network device management system.The system includes an interregional redirector system 102, a loadbalancer system 104, regional network device management systems 106-1 .. . 106-n, a computer readable medium 108 and network devices 110-1 . .. 110-n. As used in this paper, a system can be implemented as an engineor a plurality of engines.

While the system is shown to include multiple network devices 110-1 . .. 110-n, in a specific implementation, the system can only include onenetwork device (e.g. 110-1). The network device s 110-1 . . . 110-n arecoupled to client devices 112-1 . . . 112-n. Each client device can becoupled to a single network device 110-1 . . . 110-n (e.g. client device112-1) or can be coupled to more than one network device (e.g. clientdevice 112-2). The client devices 112-1 . . . 112-n can include a clientwireless device, such as a laptop computer or a smart phone. The clientdevices 112-1 . . . 112-n can also include a repeater or a plurality oflinked repeaters. Therefore, the client devices 112-1 . . . 112-n can becomprised of a plurality of repeaters and a client wireless device thatcan be coupled together as a chain.

A network device, as is used in this paper, can be an applicable deviceused in connecting a client device to a network. For example, a networkdevice can be a virtual private network (hereinafter referred to as“VPN”) gateway, a router, an access point (hereinafter referred to as“AP”), or a device switch. The network devices 110-1 . . . 110-n can beintegrated as part of router devices or as stand-alone devices coupledto upstream router devices. The network devices 110-1 . . . 110-n can becoupled to the client devices 112-1 . . . 112-n through either awireless or a wired medium. The wireless connection may or may not beIEEE 802.11-compatible. In this paper, 802.11 standards terminology isused by way of relatively well-understood example to discussimplementations that include wireless techniques that connect stationsthrough a wireless medium. A station, as used in this paper, may bereferred to as a device with a media access control (MAC) address and aphysical layer (PHY) interface to a wireless medium that complies withthe IEEE 802.11 standard. Thus, for example, client devices 112-1 . . .112-n and network devices 110-1 . . . 110-n with which the clientdevices 112-1 . . . 112-n associate can be referred to as stations, ifapplicable. IEEE 802.11a-1999, IEEE 802.11b-1999, IEEE 802.11g-2003,IEEE 802.11-2007, and IEEE 802.11n TGn Draft 8.0 (2009) are incorporatedby reference.

As used in this paper, a system that is 802.11 standards-compatible or802.11 standards-compliant complies with at least some of one or more ofthe incorporated documents' requirements and/or recommendations, orrequirements and/or recommendations from earlier drafts of thedocuments, and includes Wi-Fi systems. Wi-Fi is a non-technicaldescription generally correlated with the IEEE 802.11 standards, as wellas Wi-Fi Protected Access (WPA) and WPA2 security standards, and theExtensible Authentication Protocol (EAP) standard. In alternativeimplementations, a station may comply with a different standard thanWi-Fi or IEEE 802.11 and may be referred to as something other than a“station,” and may have different interfaces to a wireless or othermedium.

IEEE 802.3 is a working group and a collection of IEEE standardsproduced by the working group defining the physical layer and data linklayer's MAC of wired Ethernet. This is generally a local area networktechnology with some wide area network applications. Physicalconnections are typically made between nodes and/or infrastructuredevices (hubs, switches, routers) by various types of copper or fibercable. IEEE 802.3 is a technology that supports the IEEE 802.1 networkarchitecture. As is well-known in the relevant art, IEEE 802.11 is aworking group and collection of standards for implementing wirelesslocal area network (WLAN) computer communication in the 2.4, 3.6 and 5GHz frequency bands. The base version of the standard IEEE 802.11-2007has had subsequent amendments. These standards provide the basis forwireless network products using the Wi-Fi brand. IEEE 802.1 and 802.3are incorporated by reference.

The network devices 110-1 . . . 110-n are coupled to the interregionalredirector system 102, the load balancer system 104 and regional networkdevice management systems 106-1 . . . 106-n through a computer-readablemedium 108. The computer-readable medium 108 is intended to represent avariety of potentially applicable technologies. For example, thecomputer-readable medium 108 can be used to form a network or part of anetwork. Where two components are co-located on a device, thecomputer-readable medium 108 can include a bus or other data conduit orplane. Where a first component is co-located on one device and a secondcomponent is located on a different device, the computer-readable medium108 can include a wireless or wired back-end network or LAN. Thecomputer-readable medium 108 can also encompass a relevant portion of aWAN or other network, if applicable.

The computer-readable medium 108, the interregional redirector system102, the load balancer system 104, the regional network devicemanagement systems 106-1 . . . 106-n, and other applicable systemsdescribed in this paper can be implemented as parts of a computer systemor a plurality of computer systems. A computer system, as used in thispaper, is intended to be construed broadly. In general, a computersystem will include a processor, memory, non-volatile storage, and aninterface. A typical computer system will usually include at least aprocessor, memory, and a device (e.g., a bus) coupling the memory to theprocessor. The processor can be, for example, a general-purpose centralprocessing unit (CPU), such as a microprocessor, or a special-purposeprocessor, such as a microcontroller.

The memory can include, by way of example but not limitation, randomaccess memory (RAM), such as dynamic RAM (DRAM) and static RAM (SRAM).The memory can be local, remote, or distributed. As used in this paper,the term “computer-readable storage medium” is intended to include onlyphysical media, such as memory. As used in this paper, acomputer-readable medium is intended to include all mediums that arestatutory (e.g., in the United States, under 35 U.S.C. 101), and tospecifically exclude all mediums that are non-statutory in nature to theextent that the exclusion is necessary for a claim that includes thecomputer-readable medium to be valid. Known statutory computer-readablemediums include hardware (e.g., registers, random access memory (RAM),non-volatile (NV) storage, to name a few), but may or may not be limitedto hardware.

The bus can also couple the processor to the non-volatile storage. Thenon-volatile storage is often a magnetic floppy or hard disk, amagnetic-optical disk, an optical disk, a read-only memory (ROM), suchas a CD-ROM, EPROM, or EEPROM, a magnetic or optical card, or anotherform of storage for large amounts of data. Some of this data is oftenwritten, by a direct memory access process, into memory during executionof software on the computer system. The non-volatile storage can belocal, remote, or distributed. The non-volatile storage is optionalbecause systems can be created with all applicable data available inmemory.

Software is typically stored in the non-volatile storage. Indeed, forlarge programs, it may not even be possible to store the entire programin the memory. Nevertheless, it should be understood that for softwareto run, if necessary, it is moved to a computer-readable locationappropriate for processing, and for illustrative purposes, that locationis referred to as the memory in this paper. Even when software is movedto the memory for execution, the processor will typically make use ofhardware registers to store values associated with the software, andlocal cache that, ideally, serves to speed up execution. As used herein,a software program is assumed to be stored at an applicable known orconvenient location (from non-volatile storage to hardware registers)when the software program is referred to as “implemented in acomputer-readable storage medium.” A processor is considered to be“configured to execute a program” when at least one value associatedwith the program is stored in a register readable by the processor.

In one example of operation, a computer system can be controlled byoperating system software, which is a software program that includes afile management system, such as a disk operating system. One example ofoperating system software with associated file management systemsoftware is the family of operating systems known as Windows® fromMicrosoft Corporation of Redmond, Wash., and their associated filemanagement systems. Another example of operating system software withits associated file management system software is the Linux operatingsystem and its associated file management system. The file managementsystem is typically stored in the non-volatile storage and causes theprocessor to execute the various acts required by the operating systemto input and output data and to store data in the memory, includingstoring files on the non-volatile storage.

The bus can also couple the processor to the interface. The interfacecan include one or more input and/or output (I/O) devices. The I/Odevices can include, by way of example but not limitation, a keyboard, amouse or other pointing device, disk drives, printers, a scanner, andother I/O devices, including a display device. The display device caninclude, by way of example but not limitation, a cathode ray tube (CRT),liquid crystal display (LCD), or some other applicable known orconvenient display device. The interface can include one or more of amodem or network interface. It will be appreciated that a modem ornetwork interface can be considered to be part of the computer system.The interface can include an analog modem, ISDN modem, cable modem,token ring interface, satellite transmission interface (e.g. “directPC”), or other interfaces for coupling a computer system to othercomputer systems. Interfaces enable computer systems and other devicesto be coupled together in a network.

The computer systems described throughout this paper, can be compatiblewith or implemented through one or a plurality of cloud-based computingsystems. As used in this paper, a cloud-based computing system is asystem that provides virtualized computing resources, software and/orinformation to client devices. The computing resources, software and/orinformation can be virtualized by maintaining centralized services andresources that the client devices can access over a communicationinterface, such as a network. “Cloud” may be a marketing term and forthe purposes of this paper can include any of the networks describedherein. The cloud-based computing system can involve a subscription forservices or use a utility pricing model. Users can access the protocolsof the cloud-based computing system through a web browser or othercontainer application located on their client device.

The computer systems described throughout this paper can be implementedas or can include engines to perform the functions of each system. Anengine, as used in this paper, includes a dedicated or shared processorand, typically, firmware or software modules executed by the processor.Depending upon implementation-specific or other considerations, anengine can be centralized or its functionality distributed. An enginecan include special purpose hardware, firmware, or software embodied ina computer-readable medium for execution by the processor.

The engines described throughout this paper can be cloud-based engines.A cloud-based engine is an engine that can run applications and/orfunctionalities using a cloud-based computing system. All or portions ofthe applications and/or functionalities can be distributed acrossmultiple computing devices, and need not be restricted to only onecomputing device. In some embodiments, the cloud-based engines canexecute functionalities and/or modules that end users access through aweb browser or container application without having the functionalitiesand/or modules installed locally on the end-users' computing devices.

The computer systems described throughout this paper can includedatastores. A datastore, as described in this paper, can be cloud-baseddatastores compatible with a cloud-based computing system.

The regional network device management systems 106-1 . . . 106-n canfunction to manage the network devices 110-1 . . . 110-n. Each regionalnetwork device management system 106-1 . . . 106-n can include aplurality of engines that manage the network devices 110-1 . . . 110-n.The engines can be grouped into regional network device managementsystems 106-1 . . . 106-n based upon regions and subregions of thenetwork devices 110-1 . . . 110-n that the engines manage. Therefore theregional network device management systems 106-1 . . . 106-n can becharacterized by the regions and subregions of the network devices 110-1. . . 110-n that the engines within a specific network device managementsystem 106-1 . . . 106-n manage. For example, the engines that managenetwork devices 110-1 . . . 110-n in the same region or subregion can begrouped into the same regional network device management system (e.g.106-1). As a result, the regional network device management systems106-1 . . . 106-n can be regionally unique in that they contain enginesthat manage network devices 110-1 . . . 110-n within specific regions orsubregions.

As the regional network device management systems 106-1 . . . 106-n canbe implemented as a cloud-based system, and as the regional networkdevice management systems 106-1 . . . 106-n can be characterized by theregion and subregions of the network devices 110-1 . . . 110-n, theregional network device management systems 106-1 . . . 106-n can beorganized or located at regions within the cloud based upon the regionsand subregions of the network devices 110-1 . . . 110-n. Specifically,the regional network device management systems 106-1 . . . 106-n can beorganized or located at regions within the cloud based upon the regionsor the subregions of the network devices 110-1 . . . 110-n that theregional network device management systems 106-1 . . . 106-n manage. Ina specific implementation, the subregions of the network devices 110-1 .. . 110-n together form a region of the network devices 110-1 . . .110-n.

The regions or subregions of the network devices 110-1 . . . 110-n canbe defined based upon geography, an enterprise network or a combinationof both geography and an enterprise network. In a specificimplementation, the region can be defined based upon geography toinclude the network devices 110-1 . . . 110-n associated with or locatedwithin a geographical area or location, such as a city or a buildingwithin a city. Similarly, a subregion can be defined to include thenetwork devices 110-1 . . . 110-n located in or associated with ageographical area or location within the geographical area or locationused to define the region. For example, the region can be defined toinclude the network devices 110-1 . . . 110-n located in or associatedwith a state, while the subregion can be defined to include the networkdevices 110-1 . . . 110-n located in or associated with a city in thestate that defines the region. In another implementation, the region canbe defined based upon an enterprise to include the network devices 110-1. . . 110-n associated with or are used in an enterprise network. In yetanother implementation, the region can be defined based upon acombination of both geography and an enterprise to include the networkdevices 110-1 . . . 110-n associated with or located within ageographical location or area within an enterprise network. For example,the region can include the network devices 110-1 . . . 110-n associatedwith or located within a specific office site of the enterprise.

The regions of the network devices 110-1 . . . 110-n can not only bedefined according to the previously described classifications but canalso be defined based upon the number of network devices 110-1 . . .110-n in or associated with the region. In a specific implementation,the region can be defined to include only basic service set (BSS). A BSSincludes one network device and all of the stations or other devices(i.e. repeaters) coupled to the network device. The BSS can beidentified by a unique basic service set identification (BSSID). TheBSSID can be the MAC address of the network device in the BSS. Inanother implementation, the region can be defined to include an extendedservice set (ESS) that comprises plurality BSSs. The plurality of BSSscan be interconnected so that stations or devices are connected tomultiple network devices within the ESS. The ESS can be identified by aunique extended service set identification (ESSID). The ESSID can be theMAC addresses of the network devices in the ESS.

The system shown in FIG. 1 includes a load balancer system 104 coupledto the regional network device management systems 106-1 . . . 106-n andthe network devices 110-1 . . . 110-n through the computer readablemedium 108. The load balancer system 104 is also coupled to theinterregional redirector system 102 through the computer-readable medium108. The system can include multiple load balancer systems 104 that canbe coupled to and associated with different regional network devicemanagement systems 106-1 . . . 106-n. In a specific implementation, thespecific regional network device management systems 106-1 . . . 106-nthat the load balancer system 104 is coupled to and associated with canbe based upon the regions and subregions of the network devices 110-1 .. . 110-n that the engines within the specific regional network devicemanagement systems 106-1 . . . 106-n manage. For example, a loadbalancer system 104 can be coupled to and associated with the regionalnetwork device management systems 106-1 . . . 106-n that manage thenetwork devices 110-1 . . . 110-n within an entire state. As the loadbalancer systems 104 can be coupled to and associated with specificregional network device management systems 106-1 . . . 106-n based onthe regions or the subregions of the network devices 110-1 . . . 110-nthat the engines within the specific regional network device managementsystems 106-1 . . . 106-n manage, the load balancer systems 104 can beregionally unique. For example, the load balancer systems 104 can beregionally unique in that they are associated with network devices 106-1. . . 106-n in the same enterprise network.

Additionally, a specific regional network device management system 106-1. . . 106-n can be coupled to or associated with multiple load balancersystems 104 based upon the regions and subregions of the network devices110-1 . . . 110-n managed by the engines in the specific regionalnetwork device management system 106-1 . . . 106-n. For example, aspecific regional network device management system 106-1 . . . 106-n canbe coupled to or associated with a first load balancer system 104because the specific regional network device management system 106-1 . .. 106-n contains engines that manage network devices 110-1 . . . 110-nin a specific region, such as a state. Additionally, the specificregional network device management system 106-1 . . . 106-n can also becoupled to or associated with a second load balancer system 104 becausethe specific regional network device management system 106-1 . . . 106-ncontains engines that manage network devices 110-1 . . . 110-n in asubregion of the specific region, such as a city within the state.

The load balancer system 104, as will be discussed in greater detaillater with respect to FIG. 2, can function to monitor the usage ofspecific engines grouped into regional network device management systems106-1 . . . 106-n as the engines within the regional network devicemanagement systems 106-1 . . . 106-n manage various network devices110-1 . . . 110-n. The load balancer system 104 can also function toassign a network device 110-1 . . . 110-n to one or a plurality ofengines within one or more of the regional network device managementsystems 106-1 . . . 106-n so that the assigned engine or engines canmanage the assigned network devices 110-1 . . . 110-n. The load balancersystem 104 can also function to assign a network device 110-1 . . .110-n to another load balancer system 104 that can then assign thenetwork devices 110-1 . . . 110-n to another load balancer system 104 orone or a plurality of engines within one or more of the regional networkdevice management systems 106-1 . . . 106-n. In a specificimplementation, the load balancer systems 104 can assign a newlypurchased network device 110-1 . . . 110-n to either or both anotherload balancer system 104 and engines in a regional network devicemanagement system 106-1 . . . 106-n.

The load balancer systems 104 can assign the network devices 110-1 . . .110-n to specific engines within the regional network device managementsystems 106-1 . . . 106-n based upon the regions or subregions of theother network devices 110-1 . . . 110-n that the specific enginesmanage. The load balancer systems 104 can assign the network devices110-1 . . . 110-n to other load balancers systems. The other loadbalancer systems can be coupled to or associated with specific engineswithin the regional network device management systems 106-1 . . . 106-n.Specifically, the other load balancer systems can be associated withspecific engines within the regional network device management systems106-1 . . . 106-n based upon the regions or subregions of the networkdevices 110-1 . . . 110-n that the other load balancer systems assign.

The system shown in the example of FIG. 1 includes an interregionalredirector system 102. The interregional redirector system 102 iscoupled to the network devices 110-1 . . . 110-n and the load balancersystems 104 through the computer readable medium 108. In a specificimplementation, the interregional redirector system 102 is notassociated with any specific region. Specifically, the interregionalredirector system 102 can be coupled to all of the load balancer systems104, and through the load balancer systems to all of the regionalnetwork device management systems 106-1 . . . 106-n. As the regionalnetwork device management systems 106-1 . . . 106-n and the loadbalancer systems 104 can be regionally unique, and as the interregionalredirector system 102 can be coupled to all of the regional networkdevice management systems 106-1 . . . 106-n, the interregionalredirector system 102 is associated with every region or subregion.Therefore, the interregional redirector system 102 is not unique to asingle region, but is rather globally applicable to at least asubplurality of the regions.

In being coupled to the network devices 110-1 . . . 110-n, theinterregional redirector system 102 can function to receiveidentification information from the network devices 110-1 . . . 110-nand validate the network devices. In being coupled to the load balancersystems 104, the interregional redirector system 102 can furtherfunction to assign specific network devices 110-1 . . . 110-n to one ora plurality of load balancer systems 104. As the load balancer systemscan be regionally unique, the interregional redirector system 102 canassign the network devices 110-1 . . . 110-n to one or a plurality ofspecific load balancer systems 104 based upon the regions or subregionsof the network devices 110-1 . . . 110-n that are being assigned.

In a specific implementation, a newly purchased network device 110-1 . .. 110-n is configured to be directed to the interregional redirectorsystem 102 upon the first turning on of the network device 110-1 . . .110-n by the purchaser of the network device. In being directed to theinterregional redirector system 102, the network device 110-1 . . .110-n can send the identification information of the network device tothe interregional redirector system 102. The interregional redirectorsystem 102 can both validate the network device 110-1 . . . 110-n andassign the newly purchased network device 110-1 . . . 110-n based on theregion or subregion of the network device to one or a plurality of loadbalancer systems 104. The one or a plurality of load balancer systems104 can then assign the newly purchased network device 110-1 . . . 110-nto one or a plurality of regional network device management systems106-1 . . . 106-n. In another example, additional server resources, suchas additional new regional network device management systems can beadded and the load balancer system 104 can assign the newly purchasednetwork device 110-1 . . . 110-n to an added new regional network devicemanagement system.

In a specific implementation, the regions or subregions of the networkdevices 110-1 . . . 110-n can be part of the identification informationreceived by the interregional redirector system 102 from the networkdevices 110-1 . . . 110-n. In another implementation, the interregionalredirector system 102 can trace through the computer readable medium 108to determine the region or subregion of the newly purchased networkdevice 110-1 . . . 110-n. Alternatively, the interregional redirectorsystem 102 can trace through the computer readable medium 108 theregions or subregions of already activated network devices 110-1 . . .110-n that neighbor the newly purchased network device 110-1 . . . 110-neither physically or on a network structure level to determine theregion or subregion of the newly purchased network device 110-1 . . .110-n. The interregional redirector system 102 can determine the regionsor subregions of neighboring network devices 110-1 . . . 110-n basedupon the MAC addresses of the neighboring network devices 110-1 . . .110-n. In an alternate implementation, the interregional director system102 can determine the region or subregion of the newly purchased networkdevice 110-1 . . . 110-n through the identity of the purchaser of thenetwork device. Specifically, the interregional redirector system 102can use the MAC address of the newly purchased network device 110-1 . .. 110-n that can be received from the newly purchased network device110-1 . . . 110-n to determine the identity of the purchaser of thenetwork device 110-1 . . . 110-n and the region or subregion of thenetwork device 110-1 . . . 110-n. For example, the interregionalredirector system 102 can determine that company A purchased the networkdevice 110-1 . . . 110-n and because company A occupies a specificlocation within a region, such as a city, determine that the city is theregion of the newly purchased network device 110-1 . . . 110-n.

FIG. 2 depicts a diagram 200 of an example of a system configured tocouple a network device to a network device management engine andmonitor the network device management engine. The system includes aregional network device management system 202 coupled to network devices204-1, 204-3 and 204-3. While only three network devices 204-1, 204-2and 204-3 are shown, the regional network device management system 202can be coupled to more or less than three network devices. The systemcan also include an administrator system 214 coupled to the regionalnetwork device management system 202.

The regional network device management system 202 includes a loadbalancer system 206, network device management engines 208-1, 208-2 and208-3 and a network device management engine message queue 210. Whileonly three network device management engines 208-1, 208-2 and 208-3 areshown, the regional network device management system 202 can includemore or less than three network device management engines.

The network device management engines 208-1, 208-2 and 208-3, within theregional network device management systems 202, are coupled to thenetwork devices 204-1, 204-2 and 204-3. A network device (e.g. 204-3)can be coupled to more than one network device management engines (e.g.208-2 and 208-3). The network device management engines (e.g. 208-1) canmanage the flow of data into and out of the network devices (e.g. 204-1)coupled to the specific network device management engines (e.g. 208-1).The network device management engines (e.g. 208-1) can be regionallyunique in that they manage the flow of data into and out of the networkdevices in specific regions or subregions. Furthermore, the networkdevice management engines can be grouped into a network devicemanagement system 202 based upon the regions or subregions of thenetwork devices that the network device management engines manage.

In a specific implementation, the network device management engines208-1, 208-2 and 208-3 can manage the flow of data into and out of thenetwork devices 204-1, 204-2 and 204-3 by controlling routers connectedto the network devices. In another implementation, the network devicemanagement engines 208-1, 208-2 and 208-3 can control the flow of datainto and out of the network devices 204-1, 204-2 and 204-3 byfunctioning as a router themselves, and switching between different datapaths coupled to the network device management engines. For example,network device management engines 208-1, 208-2 and 208-3 that managenetwork devices 204-1, 204-2 and 204-3 within the same region orsubregion can be grouped into the same network device management system202.

The network device management engines 208-1, 208-2 and 208-3 can be aserver that can perform the previously described functions. In aspecific implementation, the network device management engines 208-1,208-2 and 208-3 can be configured in accordance with the control andprovisioning of wireless access points (CAPWAP) protocol. Specifically,the network device management engines 208-1, 208-2 and 208-3 can beCAPWAP servers. CAPWAP servers are servers that can be configured inaccordance with the CAPWAP protocol. The CAPWAP protocol is similar tothe light weight access point protocol (LWAPP), but differs in that itincludes the integration of a full datagram transport layer security(DTLS) tunnel. Data is transmitted through the CAPWAP protocol over anunencrypted data channel while control messages of the data aretransmitted in the DTLS tunnel. The CAPWAP protocol is described in RFC5415 (2009), which is hereby incorporated by reference, and IEEE 802.11which was previously incorporated by reference.

In a specific implementation, the network devices 204-1, 204-2 and 204-3can function to determine whether a network device management engine208-1, 208-2 and 208-3 that the network devices are coupled to hasfailed. For example, if a network device 204-1, 204-2 and 204-3 does notreceive traffic from a network device management engine 208-1, 208-2 and208-3 that is coupled to the network device, then the network device candetermine that the network device management engine has failed. Furtherin the specific implementation, the network device 204-1, 204-2 and204-3 can alert the load balancer system 206 to a failure of a networkdevice management engine 208-1, 208-2 and 208-3. For example, upondetecting a failure in a network device management engine 208-1, 208-2and 208-3 can generate and send a network device management enginefailure message to the load balancer system 206. In one example, thenetwork device management engine failure message identifies the specificnetwork device management engine 208-1, 208-2 and 208-3 that has failed.

The network device management engines 208-1, 208-2 and 208-3 are coupledto the network device management engine message queue 210. The networkdevice management engine message queue 210 is coupled to the loadbalancer system 206. The network device management engine message queue210 can function to receive status messages sent from the network devicemanagement engines 208-1, 208-2 and 208-3. The status messages can besent from the network device management engines 208-1, 208-2 and 208-3periodically, after a predetermined interval of time. In anotherimplementation the status messages can be sent from the network devicemanagement engines 208-1, 208-2 and 208-3 when the load balancer system206 sends a status request to the network device management engines208-1, 208-2 and 208-3.

The status messages sent from the network device management engine208-1, 208-2 and 208-3 can include the amount of used bandwidth andavailable bandwidth that exist on network devices coupled to thespecific network device management engines 208-1, 208-2 and 208-3. Thestatus messages can also include information about the number of networkdevices 204-1, 204-2 and 204-3 that the network device managementengines 208-1, 208-2 and 208-3 are managing. The status messages canfurther include the amount of bandwidth on the network device managementengines 208-1, 208-2 and 208-3 that each network device 204-1, 204-2 and204-3 is using. In a specific implementation, the regions and subregionsof the network devices 204-1, 204-2 and 204-3 that the network devicemanagement engines 208-1, 208-2 and 208-3 are managing is included inthe status messages. Further, the status message can include the amountof memory available and is being used by the network device managementengines 208-1, 208-2 and 208-3 and how much memory of the network devicemanagement engines is being used by each network device 204-1, 204-2 and204-3 managed by the network device management engines 208-1, 208-2 and208-3.

The load balancer system 206 is also coupled to the network devices204-1, 204-2 and 204-3. The load balancer system 206 can become coupledto network devices 204-1, 204-2 and 204-3 when the network device 204-1,204-2 and 204-3 is assigned to the specific load balancer system 206 ofa specific regional network device management system 202. The networkdevices 204-1, 204-2 and 204-3 can be assigned to a specific loadbalancer system 206 within a specific regional network device managementsystem 202 by either another load balancer system 104 or theinterregional redirector system 102, shown in FIG. 1. As discussedpreviously with FIG. 1, the network device 204-1, 204-2 and 204-3 can beassigned to a specific regional network device management system 202based on the region or subregion of the network device 204-1, 204-2 and204-3.

The load balancer system 206 can function to assign a network device204-1, 204-2 and 204-3 to a network device management engine 208-1,208-2 and 208-3 when the network device 204-1, 204-2 and 204-3 isassigned to the load balancer system 206. In a specific implementation,the load balancer system 206 can assign a newly purchased network device204-1, 204-2 and 204-3 to a network device management engine 208-1,208-2 and 208-3. The load balancer system 206 can assign a networkdevice 204-1, 204-2 and 204-3 to a network device management engine208-1, 208-2 and 208-3 based upon the region or subregion of the networkdevices already assigned to a network device management engine. Forexample, the load balancer system 206 can assign a network device 204-1,204-2 and 204-3 to a network device management engine 208-1, 208-2 and208-3 that already manages network devices in the same or related regionor subregion of the network device that is being assigned.

Additionally, the load balancer system 206 can assign the network device204-1, 204-2 and 204-3 to one or a plurality of network devicemanagement engines 208-1, 208-2 and 208-3 based in part upon the statusmessage that the load balancer system 206 reads for each network devicemanagement engine 208-1, 208-2 and 208-3 from the network devicemanagement engine message queue 210. For example, if the status messagesretrieved by the load balancer system 206 indicate that network devicemanagement engine 208-1 has a greater amount of bandwidth than networkdevice management engine 208-2, the load balancer system 206 can assignnetwork device 204-1 to network device management engine 208-1. As aresult, network device 204-1 is managed by network device managementengine 208-1. In another implementation, the load balancer system 206can also assign the network device 204-1, 204-2 and 204-3 to a networkdevice management engine 208-1, 208-2 and 208-3 based not only on theavailable bandwidth of the network device management engines, but alsoon the expected amount of resources, such as bandwidth that the specificnetwork device 204-1, 204-2 and 204-3 will use from the network devicemanagement engines.

The load balancer system 206 can also function to monitor the status ofthe network device management engines 208-1, 208-2 and 208-3 andreassign the network devices 204-1, 204-2 and 204-3 to other networkdevice management engines in the event of a failure of the networkdevice management engine or engines 208-1, 208-2 and 208-3 to whichspecific network devices are assigned. For example, the load balancersystem 206 can detect a failure in network device management engine208-1 connected along dashed line 212 to network device 204-2. Inresponse to the failure of network device management engine 208-1, theload balancer system 206 can assign the network device 204-2 to networkdevice management engine 208-2 that is not failing.

In a specific implementation, the load balancer system 206 detects afailure of a network device management engine 208-1, 208-2 and 208-3when the network device management engine does not send a status messageto the network device management engine message queue 210. In anotherimplementation, the load balancer system 206 detects a failure of anetwork device management engine 208-1, 208-2 and 208-3 when the enginedoes not send a specific number of status messages to the network devicemanagement engine message queue 210. The number of status messages thata network device management engine 208-1, 208-2 and 208-3 fails to sendto the network device management engine message queue 210 before theload balancer system 206 determines that a failure has occurred can bepredefined. In another implementation, the load balancer system 206detects a failure of a network device management engine 208-1, 208-2 and208-3 when the status message sent by a network device management engineindicates that the resources of the engine reach a certain level. Forexample, the load balancer system 206 can detect a failure of one of thespecific network device management engine 208-1, 208-2 and 208-3 whenthe amount of available bandwidth of the specific network devicemanagement engines falls below a certain predefined available bandwidthlevel.

In a specific implementation, the load balancer system 206 functions todetect a failure of a network device management engine based on networkdevice management engine failure messages generated by the networkdevices 204-1, 204-2 and 204-3. For example, if the load balancer system206 receives a network device management engine failure message from thenetwork devices 204-1, 204-2 and 204-3 identifying the specific networkdevice management engine 208-1, 208-2 and 208-3 that has failed, thenthe load balancer system 206 can determine/detect that the specificnetwork device management engine 208-1, 208-2 and 208-3 has failed.

In a specific implementation, if the load balancer system 206 detects afailure in one of the network device management engines 208-1, 208-2 and208-3, the load balancer system 206 can reassign the one or plurality ofnetwork devices 204-1, 204-2 and 204-3 connected to the network devicemanagement engine to other network device management engines in eitherthe same regional network device management system 202 or differentregional network device management systems. Alternatively, the loadbalancer system 206 can reassign all of the network devices 204-1, 204-2and 204-3 connected to a failed network device management engine 208-1,208-2 and 208-3 to one or a plurality of other network device managementengines. In yet another alternative, the load balancer system canreassign a portion of the network devices 204-1, 204-2 and 204-3connected to a failed network device management engine 208-1, 208-2 and208-3 so that the failed network device management engine is cured, andis no longer failing. For example, if a network device management engineis failing due to a lack of available bandwidth, the load balancersystem 206 can reassign a portion of the network devices assigned to thefailed network device management engine so that the available bandwidthof the failing network device management engine is increased to a levelwhere the network device management engine is no longer failing.

The load balancer system 206 can also be coupled to the administratorsystem 214, thereby coupling the regional network device managementsystem 202 to the administrator system 214. The load balancer system 206can send a notification to the administrator system 214 in the eventthat the load balancer system detects a failure of one of the networkdevice management engines 208-1, 208-2 and 208-3 from the statusmessages sent to the network device management engine queue 210. In aspecific implementation, when the load balancer system 206 detects afailure of one of the network device management engines 208-1, 208-2 and208-3 because a specific network device management engine does not senda status message to the network device management engine message queue210, the load balancer system can send a notification to theadministrator system 214. The notification sent to the administratorsystem can include the reason why the load balancer system 206 detects afault in a specific network device management engine, such as a failurecaused by not sending a status message to network device managementengine message queue 210, or caused by the resources of a specificnetwork device management engine have reached a specific level. Theadministrator system 214 can include a computer implemented process forfixing the failed network device management engine based upon the reasonwhy the load balancer system 206 detects a failure in a specific networkdevice management engine.

FIG. 3 is a diagram 300 of an example of a load balancer system 302. Theload balancer system 302 can be configured to assign network devices tonetwork device management engines, monitor the status of the networkmanagement engines, reassign a network device to a new network devicemanagement engine if the network device management engine fails andnotify the administrator system of a failure of a network managementengine.

In the example of FIG. 3, the load balancer system 302 is coupledthrough computer-readable medium 304 to an administrator system 306,network devices 308 and the network device management engine messagequeue 310. The load balancer system 302 includes a message queue accessengine 314 coupled through the computer readable medium to the networkdevice management engine message queue 310. The message queue accessengine 314 can be configured to retrieve status information of networkdevice management engines from the status messages in the network devicemanagement engine message queue 310. The status messages can includeinformation as to the status of the network device management engines,such as the amount of available bandwidth on the network devicemanagement engines. The status message also can include information asto when a status message was sent to the network device managementengine message queue 310, which can be used to determine whether anetwork device management engine has stopped sending status messages,and thus may have failed. The message queue access engine 314 can beconfigured to retrieve status information each time a status message issent to the network device management engine message queue 310. Thestatus information retrieved by the message queue access engine 314 canbe stored on a network device management engine status profilesdatastore 318.

The load balancer system 302 can also include a network device accessengine 312. The network device access engine 312 can be coupled tonetwork devices 308 coupled to the load balancer system 302 throughcomputer-readable medium 304. The network device access engine 312 canbe configured to retrieve or receive information from network devices308 coupled to the load balancer system 302.

In a specific implementation, the network device access engine 312 isconfigured to retrieve or receive information from newly purchasednetwork devices 308 coupled to the load balancer system 302 for thefirst time. The newly purchased network devices can become coupled tothe load balancer system 302 after being assigned to the load balancersystem 302 by either or both another load balancer system or aninterregional redirector system, as is shown in FIG. 1. The informationretrieved or received by the network device access engine 312 caninclude the region or subregions of the network device 308. Theinformation can also include the amount of bandwidth that the networkdevice 308 expects to use. The network device access engine 312 canstore the information retrieved or received from the network devices 308on a network device profiles datastore 316.

The load balancer system 302 includes a network device assignment engine320. The network device assignment engine 320 is coupled to the networkdevice management engine status profiles datastore 318 and the networkdevice profiles datastore 316. The network device assignment engine 320is also coupled to the network devices 308 through the computer-readablemedium 304. The network device assignment engine 320 can function toassign a network device 308 to one or a plurality of network devicemanagement engines. Specifically, as the network devices 308 are coupledto the network device assignment engine 320, in assigning the networkdevices 308 to network device management engines, the network deviceassignment engine 320 can direct the network devices 308 to couple tonetwork device management engines, so that the engines can manage theflow of data packets into and out of the network devices 308. Thenetwork device assignment engine 320 can store the assignmentinformation on the network device management engine assignment profilesdatastore 322. The assignment information can include which networkdevices 308 are assigned to be managed by specific network devicemanagement engines.

The network device assignment engine 320 can also function to determinethat a network device 308 is assigned to a failing network devicemanagement engine and reassign the network device 308 to another one orplurality of network device management engines that are not failing.Specifically, the network device assignment engine 320 can determinethat a network device management engine is failing from the informationstored in the network device management engine status profiles datastore318. The network device assignment engine can then determine whichnetwork devices 308 are being managed by the specific network devicemanagement engine that is failing from the network device managementengine assignment profiles datastore 322. The network device assignmentengine 320 can then reassign the network devices 308 that are beingmanaged by failing network device management engines to differentnetwork device management engines that are not failing. In a specificimplementation, in reassigning the network devices 308 to differentnetwork device management engines the network device assignment engine320 can use the information about the network devices 308 stored in thenetwork device profiled datastore 316. For example, the network deviceassignment engine 320 can use the information about the region orsubregion of the network device 308 to reassign the network device 308to another network device management engine.

The network device assignment engine 320 can also be coupled to theadministrator system notification engine 324. The administrator systemnotification engine 324 is coupled to the administrator system 306through the computer-readable medium 304. In a specific implementation,the network device assignment engine 320 can function to initiate thesending of a notification about the failure of an AP management engineto the administrator system 306.

Specifically, the network device assignment engine 320 can send failureinformation about a network device management engine to theadministrator system notification engine 324. The failure informationcan include why the network device assignment engine 320 has determinedthat a network device management engine has failed. The administratorsystem notification engine 324 can send a notification to theadministrator system that a network device management engine has failed,as can be determined by the network device assignment engine 320. Thenotification sent by the administrator system notification engine 324can include the information used by the network device assignment engine320 to determine that the network device management engine has failed.

FIG. 4 depicts a flowchart 400 of an example of a method for assigning anetwork device to a regional network device management system. Theflowchart starts at module 402 with powering on a network device. In aspecific implementation, the network device can be a newly purchaseddevice that is powered on for the first time by the purchaser of thenetwork device.

In the example of FIG. 4, the flowchart continues to module 404 withconnecting the network device to the interregional redirector system.The flowchart continues to module 406 where the interregional redirectorsystem receives information about the network device connected to theinterregional redirector system at module 404. The information about thenetwork device can include information about the region or subregion ofthe network device. The information about the network device can alsoinclude the MAC address of the network device and information about thepurchaser of the network device. The information about the networkdevice can also include the amount of bandwidth that the network deviceexpects to use.

The flowchart then continues to module 408, where the network device isvalidated. In one example, the interregional redirector system validatesthe network device by using the MAC address received from the networkdevice. The flowchart continues to module 410, where the network deviceis assigned to a load balancer system. In one example, the interregionalredirector system can assign the network device to a load balancersystem based on the region or the subregion of the network device. Inanother example, the load balancer system can be associated with asingle or multiple regional AP management systems. In still anotherexample, the region or the subregion of the network device can bedetermined from the network device at module 406.

FIG. 5 depicts a flowchart 500 of an example of a method of a loadbalancer system assigning a network device to a network devicemanagement engine. In one example, the flowchart can further include theload balancer system determining whether or not a network devicemanagement engine has failed and reassigning network devices that arebeing managed by the failed network device management engine to othernetwork device management engine.

The flowchart beings at module 502, where a load balancer systemreceives network device information. The network device information canbe received from a network device assigned to the load balancer systemor from another load balancer system or interregional redirector systemthat assigns the network device to the load balancer system. The networkdevice information can include information about the region or thesubregion of the network device assigned to the load balancer system.The flowchart continues to module 504, where the load balancer systemreceives network device management engine information. The managementengine information can be status information of the network devicemanagement engines. The status information can be determined by the loadbalancer system from messages sent to a network device management enginemessage queue from network device management engines. The statusinformation can include the amount of bandwidth available on a networkdevice management engine. The status information can also includewhether or not the network device management engine has failed. Thestatus information can also include any other information related tonetwork device management engines that has been discussed in this paper.

The flowchart continues to module 506 where the load balancer systemassigns a network device to a network device management engine or aplurality of network device management engines for management of thenetwork device. As discussed previously, the load balancer system canassign a network device to a network device management engine based onthe region of the network device and the regions or subregions of theother network devices that the assigned network device management engineare managing. The load balancer system can also assign a network deviceto a network device management engine based on the amount of availablebandwidth that the network device management has or any other methoddescribed in this paper.

The flowchart continues to module 508, where the load balancer systemretrieves network device management engine status messages from anetwork device management engine message queue. The status messages caninclude information as to the amount of available bandwidth that anetwork device management engine has. The status messages can alsoinclude time stamps to determine when the status message was sent to thenetwork device management engine message queue by the network devicemanagement engines. The load balancer system can continuously retrievestatus messages from the network device management engine message queue,or at set times when the network device management engines are scheduledto send a status message.

The flowchart continues to module 510, where the load balancer systemmonitors a network device management engine and determines the status ofa network device management engine. The load balancer system can use thenumber of times that a network device management engine was supposed tosend a status message and did not do so in order to determine the statusof the network device management engine. Alternatively, the loadbalancer system can use the available bandwidth to determine the statusof a network device management engine.

The flowchart continues to decision point 512, where the load balancersystem determines whether the network device management engine hasfailed. The load balancer system can determine whether a network devicemanagement engine has failed based on the status of the network devicemanagement engine determined at module 510. For example, if the networkdevice management engine was supposed to send a status message and didnot do so, then the load balancer system can determine that the networkdevice management engine has failed. Alternatively, if the networkdevice management engine does not have enough available bandwidth or thenetwork devices coupled to the network device management engine do nothave enough available bandwidth then the load balancer system candetermine that the network device management engine has failed. If it isdetermined at decision point 512, that the network device managementengine has not failed, then the flowchart proceeds to module 508, wherethe load balancer system retrieves network device management enginestatus messages. At decision point 512, if the load balancer systemdetermines that a network device management engine has failed, then theflowchart continues to module 514, where the load balancer system sendsa notification to an administrator system that a specific network devicemanagement engine has failed. The flowchart then proceeds to module 506,where the load balancer system reassigns the network device to a newnetwork device management engine. In an alternative implementation, ifthe load balancer system determines at decision point 512 that a networkdevice management engine has failed, then the flowchart skips module 514and proceeds to module 506, where the load balancer system reassigns thenetwork device to a new network device management engine.

FIG. 6 depicts a flowchart 600 of an example of a method for determiningthat a network device management engine has failed by a network devicemanaged by the network device management engine. The flowchart begins atmodule 602, with determining that a network device management engine hasfailed by a network device that is managed by the network devicemanagement engine. In one example, the network device determines thatthe network device management engine has failed when the network devicestops receiving traffic from the network device management engine.

The flowchart continues to module 604 where a network device managementengine failure message is sent from the network device to a loadbalancer system. In one example, the network device generates and sendsthe network device management engine failure message to the loadbalancer system after determining that the network device managementengine has failed. In another example, the network device managementengine failure message identifies the network device management enginethat has failed.

The flowchart continues to module 606 where the load balancer systemdetects that the network device management engine has failed. In oneexample, the load balancer system detects that the network devicemanagement engine has failed after receiving the network devicemanagement engine failure message sent from the network device at module604. In another example, the load balancer system determines theidentification of the failed network device management engine from thenetwork device management engine failure message sent by the networkdevice.

The flowchart continues to module 608 where the load balancer reassignsa new network device management engine to the network device. In oneexample, the new network device management engine is in the same regionor subregion as the network device. In another example, the new networkdevice management engine manages other network devices in the sameregion or subregion as the network device to which the network devicemanagement engine is being assigned.

While preferred implementations of the present inventive apparatus andmethod have been described, it is to be understood that theimplementations described are illustrative only and that the scope ofthe implementations of the present inventive apparatus and method is tobe defined solely by the appended claims when accorded a full range ofequivalence, many variations and modifications naturally occurring tothose of skill in the art from a perusal thereof.

1. A method for building and maintaining a network comprising:operationally connecting a network device to an interregional redirectorengine; receiving at the interregional redirector engine network deviceinformation of the network device; assigning, by the interregionalredirector engine, the network device to a load balancer system.